perm filename DESCR[RDG,DBL]6 blob
sn#543035 filedate 1980-10-24 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00012 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 RLL TALK
C00006 00003 Add/Change to memo, next iteration:
C00011 00004 Criteria for Paper (esp AAAI)
C00017 00005 Short description (for AAAI Article)
C00034 00006 Version of Short PCohen rewrote (June 1980) [Taken from previous page]
C00037 00007 Mailed to NII (LENAT/CC) 18:50 26-June
C00048 00008 Mailed to CSD.NII@SCORE 15:41 3-July
C00060 00009 Received from NII 7-July (essentially final form)
C00070 00010 Comparison to Editors
C00072 00011 Language metaphor
C00076 00012 Ref:
C00081 ENDMK
C⊗;
RLL TALK
Hillel metaphor:
"Tell me what's in the Torah, while I stand on one foot."
other fellow -> go away
Hillel -> "Do not do ... " The rest is just example and ...
Similarly what is in RLL-1 is just simple, single idea:
Leave parts of the representation explicit, and modifiable --
using same formalism as what is conventionally called "data".
The rest of just implementation.
This talk will first provide motivation -- why this is a good idea, and
why and how it can, at all, work.
Then specifics of RLL-1 ...
<<Table with missing leg for Problem 1; Hammer and Nail for Soln (rep'n lang)>>
<<Broken cup for Problem 2; Glue for Soln (rep'n lang)>>
Let us pause here and ask why LISP is in such common usage --
what advantages does it have over, say, Fortran (well, we know why not
Fortran) over, say, Pascal or the other "good" (structured) languages?
Answer is clear - Lisp is flexible and adaptable to new situations.
How does this happen: LISP code is identical, in form, to the data
it can use -- they are all S-Expressions. And LISP knows how to deal
with S-expressions in general, and hence can modify code with the
same ease as it can manipulate data in general.
Add/Change to memo, next iteration:
0. Page numbers - there should be a blank page after the title.
1. Glossary:
Language, Representation, Rep'n Language, Semantics
rll, RLL-1,
Slot Type, slot, unit, proposition, class of units, typical member, defaults
2. Example of RLL in action - perhaps spill problem (with its control process)
3. Move much of Section 4.3 (example of defining a new type of slot using HLDefn)
to Appendix A, so this just points there.
4. Further details
FAST-CACHE, FAST-GET for GetValue
Fast-Cache for CacheValue
Fast-Put for PutValue
Add on ways of handling quantification
[Maybe Mike's 13 facts]
Note at end that we are changing it so each unit (well, each KB) knows how to
access its slots, ...
Section numbers of Appendix F, about Functions, mislabeled (with D.2, ...)
"Developped"
Enough for PRIMER - i.e. minimal set of commands the user must know.
(Anne's suggestion)
Present FIRST as static interpreter, then go on to show how that might be changed.
Westfold, Steve [mispelled ...]
What is our purpose -- i.e.
Verification - RLL is a success when ____.
i) Given any new rep'n item, we can nod our head, realizing it could be done
ii) Others abandon their systems, realizing RLL's generality subsumes
such systems
In overview:
There is one major distinction between what the name r..l..l.. implies, and
what this system really is and does. When you modify some part of the
networks which describes/represents VLSI, you do NOT produce a new chip --
that is, the referent of these symbols is, of course, unchanged.
Changes to RLL-1, however, may have more far ranging effects -- the system
itself (that is, what these various symbols are actually describing) are
changed by commands to RLL-1. Like Dorian Grey, changing these symbols
causes their extensions to be altered.
Add: ref to Music Encycl, for Bach; also Dorian Grey
Criteria for Paper (esp AAAI)
1) Precise Statement of our goals
2) Where does power derive?
3) Verification
1) Precise Statement of our goals -
To develop a body of mechanisms (read language) in which one can
represent the components of a RL, and their interactions.
(Components include:
Slots, Inheritance Mechanism, Matchers, Verifiers, ?Semantics? )
Include hierarchy of existing pieces - taken from Klone, KRL, ...,
user can pick and choose
Note it is NOT required that we (explicitly) encode every possible rep'nal
construct -- our goal is to be able to develope such, readily.
Short description (for AAAI Article)
Implementing a complex AI task using begins by designing and building a
suitable representation language, in which to express the primitives of
this domain are easy to express and manipulate. (eg Parsing Trees for NL,
or Experiment Planning for MOLGEN.) The representation language used in
one domain is very seldom borrowed and adaptated to serve for some other
application -- the facilities which were desirable assets for the original
task become limitations elsewhere. Most such languages are therefore
built essentially from scratch -- a very time consuming (and, we believe,
avoidable) task.
Realizing this problem, we built a language in which the components of a
representation language could be described and built, and integrated into
a new representation language. This Representation Language Language,
RLL, provides a body of high level constructs which the user can apply
when designing his new language, [significantly speeding up this first
step.] RLL includes a large library of "representational pieces", e.g.
including the mode of inheritance used by the Examples link of the Units
package, or the A-Kind-Of type of slot associated with FRL. A novice user
can easily design his system by simply choosing the precise amalgamation
of these pieces he wishes. RLL is then responsible for meshing these
parts together, to form a coherent and working whole.
A more advanced user can exploit RLL's mechanisms for designing new parts
-- for example, a new inheritance, or new type of format permissable for a
slot. He could then use these in the system he is building. Once again,
the use of high level operators (such as Create-New-Inheritance-Like(
InstanceOf )) will vastly lessen the time required to construct this
desired language (compared to using, say, CAR, CDR and COND).
While several people have expressed interest in using RLL for their
applications, the system has only recently become sufficiently stable to
permit others to use it. It has been involved in two small, internal
tasks -- an adventure game simulation and an exploration into a more
complete self-description of various of its parts, using lower-level
primitives.
This research has forced us to examine a variety of issues -- ranging from
"what's in a language" concerns, which asks just what are the constituent
parts of a representation language, to epistomological questions, such as
how to handle intentional objects, or syntactic slots.
The details of how RLL was designed can be found in [Greiner 1980]; and
our proposals for solving many of the outstanding issues and questions are
in [Greiner and Lenat 1980] and [Genesereth and Lenat 1980]. Finally,
Dave Smith's demand paging system, CORLL, frees RLL from InterLisp's 256K
storage limitation.
Ref:
Genesereth, Micheal, and Lenat, Douglas B., "?", HPP Working Paper 80-?,
June 1980.
Greiner, Russell, "A Representation Language
Language", HPP Working Paer 80-9.
Greiner, Russell and Lenat, Douglas B., "A Representation Language
Language", submitted to this AAAI.
Smith, David E., "CORLL: A Demand Paging System for Units", HPP Working
Paper 80-8, June 1980.
Version of Short PCohen rewrote (June 1980) [Taken from previous page]
Implementing a complex AI task often begins by designing and
building a suitable representation language, in which the primitives
of the domain are easy to express and manipulate. The representation
language used in one domain is seldom borrowed and adapted to
another, because the facilities that were assets for one task become
limitations elsewhere. For this reason, most such languages are built
from scratch. The goal of the RLL effort is to reduce the amount of
time expended in building a representation language, by providing a
Representation Language Language, that is, a language that provides
the user with the components of many representation languages, and
with the ability to integrate them. RLL contains a large library of
"representational pieces", for example, the mode of inheritance used
by the Examples link of the Units package, or the A-Kind-Of type of
slot used in the MIT Frames Representation Language, FRL. A novice
user can easily design a language simply by picking an amalgamation
of pieces; RLL is responsible for meshing them together into a
coherent and working whole. A more advanced user can exploit RLL's
mechanisms for designing new parts, for example, a new mode of
inheritance, or a new type of format for a slot. He could then use
these in the system he is building. The use of high level operators
(e.g. "Create-New-Inheritance-Like(Instance-Of)") will greatly lessen
the time required to construct the desired language.
The RLL system is an ongoing effort. It has recently been
used in two small, internal tasks, an adventure game simulation and
an exploration into a more complete self-description of various of
its parts, using lower level primitives.
Mailed to NII (LENAT/CC) 18:50 26-June
Short description (for NII's HPP Brochure)
Motivation
Implementing a complex AI task usually begins by building such a
representation language. This language is designed to facilitate the
expression and manipulation of the primitives of this particular domain.
Experience has shown that the language used in one domain is seldom
borrowed and adaptated to serve for some other application: The
facilities which were desirable assets for the original task become
limitations elsewhere. Most such languages are built essentially from
scratch -- a very time consuming (and, we believe, avoidable) task.
Task Description
To speed up this first step, we built a language which "knows" about the
components of representation languages in general. This Representation
Language Language, RLL, provides an extendable collection of high level
operators and constructs, which can be used to describe and build such
components. It can then integrate these pieces into a functional, new
representation language. The user can use these functions to design his
"personal" language, capable of dealing with the problems associated with
his specfic domain and application.
RLL's open-ended means there were be an extendable set of possible
representational pieces. The current system knows about slots, modes of
inheritance, specification for functions, etc. (Much of the nomenclature,
such as Unit and Slot, is taken from the UNITS package, described
earlier.) (A sample mode of inheritance is the one associated with the
Examples link of the Units package, which corresponds to "element-of".)
Most operators are methods for defining or refining such pieces. For
example, RLL allows the user to define the "Parents" slot as the union of
the "Mother" and "Father" slots -- that is, (the value of) the "Parents"
slot of an individual is a list consisting of (the value of) that person's
"Mother" slot, and (the value of) his "Father" slot. This brief
definition alone is sufficient to tell RLL everything it needs to know
about this slot. RLL will automatically invalidate the value stored for
Fred's parents if his mother remarries; and know that only some units may
have a Parents slots (viz. those which had both a Mother and Father slot
-- i.e. people).
RLL includes a large library of pre-fabricated "representational pieces".
In fact, a novice can easily design his language by simply choosing the
precise amalgamation of these pieces he wishes. RLL will then mesh these
parts together, to form a coherent and working whole.
A more advanced user can exploit RLL's mechanisms for designing new parts.
The "Father" example above illustrates the ease associated with defining a
new slot; designing a new inheritance, or new type of format is as easy.
As before, the host of high level operators considerably lessens the
complexity associated with constructing and integrating this new piece.
Using these parts (however they were derived,) as tools, the user can then
procede with his main task. If he later discovers limitations in this set
of facilities, he need only redesign the offending components. RLL's high
level operators make such modifications easy to perform; furthermore, RLL
will automatically perform any necessary reformatting of the existing data
to conform to this new, just defined set of conventions.
Current Applications
While several people have expressed interest in using RLL for their
applications, the system has only recently become sufficiently stable to
permit others to use it. It has been involved in two small, internal
tasks -- an adventure game simulation and an exploration into a more
complete self-description of various of its parts, using lower-level
primitives.
An brief overview of RLL's goals can be found in [Greiner & Lenat]. This
is expanded in [Greiner 1980], which illustrating many additional aspects
of RLL's design and implementation. Finally, an important stand-alone
submodule of RLL is its demand paging system, CORLL, which frees RLL from
InterLisp's 256K storage limitation. (See [Smith 1980].)
Ref:
Greiner, Russell, "A Representation Language Language", HPP Working Paper
80-9, June 1980.
Greiner, Russell and Lenat, Douglas B., "A Representation Language
Language", AAAI Conference, Stanford, 1980.
Smith, David E., "CORLL: A Demand Paging System for Units", HPP Working
Paper 80-8, June 1980.
∂Date: 27 Jun 1980 1442-PDT
From: Nii at SUMEX-AIM
Subject: Re: Short RLL Description
To: RDG at SU-AI
cc: lenat
In response to your message sent 26 Jun 1980 1850-PDT
Russ,
The piece you wrote is really nice and is much appreciated.
I'll go over it Doug to get his ok
penny
-------
∂Date: 3 Jul 1980 1119-PDT
From: CSD.NII at SU-SCORE
Subject: RLL article
To: csd.greiner at SU-SCORE, rdg at SU-AI
cc: csd.nii at SU-SCORE
I've fixed the first 2-3 paragraphs of the RLL article. It is
unprotected and is in my directory at SCORE (do not use the one
at Sumex) <csd.nii>broch.rll. We are fast reaching a deadline so
could you get it back to me as soon as possible.
penny
-------
∂Date: 6 Jul 1980 1403-PDT - Nii at SUMEX-AIM - Rll write-up
To: rdg at SU-AI
cc: nii, Lenat
Russ,
I did some text editing to the version you gave me to save time.
I don't believe I changed any meanings intended in the paper. Please
look is over and see if you are satisfied--it's in <nii>broch.rll@sumex.
Meta-comments
1. Try to avoid too many parenthetical remarks. They are reserved for
statements which can be skipped over. Either something is worth
saying or it isn't. I took out most of the parentheses and made them
into regular text.
2. Unnecesary uses of "this" and "that"'s. Since the text progression
is quite logical, I replaced most of them with "the" or repeated the
references.
3. Look out for parallel constructs--avoid split infinitives.
4. Use commas, ;, and -- appropriately.
Since English is my second language, I'm not the one to criticize other's
English. However, there are some heuristics that can be learned that
might make your writing task a little easier and smoother.
penny
-------
Mailed to NI@SUMEX (& LENAT/cc) 13:03 7-July
Penny,
That document seemed good. I have (only) a few suggsted modifications;
our words do seem to be converging. One more iteration? When?
Russ
Mailed to CSD.NII@SCORE 15:41 3-July
Motivation
RLL is a tool to facilitiate the building of expert programs quickly. It
is itself an expert program, whose domain of expertise is knowledge
representation.
Task Description
The standard first step taken in building an application program (in AI)
is the design and implementation of a language which will be used
represent the knowledge this program will use. Experience has shown that
the language developed in one application is seldom adaptated for use in
other programs. The features that were useful for the original problem
become limitations elsewhere. Thus, a specialized representation language
is redesigned and reimplemented for each application -- a very time
consuming task.
RLL (Representation Language Language) is designed to reduce the time
spent building such representation languages. It is a language which
"knows" about the components of representation languages in general. It
provides the user with an extendable collection of high level operators
and constructs which he can use to describe and build components of his
target language. After the user has specified the desirable features of
the target language, RLL integrates these components into a functional,
new representation language. In other words, a user can readily (and
rapidly) design a personalized language, exactly suited to the domain and
the application task at hand.
RLL's open-ended means there were be an extendable set of possible
representational pieces. The current system can deal with pieces such as
slots, modes of inheritance, and specification for functions. Slots
conform to the definition given in the UNITS package description,
appearing earlier. (In fact, RLL borrowed much of its nomenclature, as
well as software, from this system. [Footnote: One example is a
stand-alone submodule of RLL, which implements a demand paging system.
This frees RLL from InterLisp's 256K storage limitation. (See [Smith].])
UNITs also motivated an important mode of inheritance: the one associated
with its Examples link. (This relationship corresponds to set theory
notion of "element-of".) There is nothing in UNITS which corresponds to
our use of functional specification. We are currently exploring this
domain, which helps unify many outwardly diverse concepts, such as
processes, mechanisms, and slots.
The initial RLL system is itself a very versatile representation language.
For most tasks, the user can use it as he might any other representation
language. What distinguishes RLL is that the user is not forced to follow
the constraints imposed by this particular language; instead, he can mold
his copy of RLL to accomodate his particular task.
RLL derives this flexibility in two ways. First, RLL contains a large
library of largely independent, pre-fabricated "representational pieces".
For example, there are many (mutually incompatible) ways in which one can
associate facts with an object. One corresponds to UNIT's idea of a slot,
while another is to let each unit point the list of assertions in which it
is involves. (Consider how to represent "Fred is the Father of Mary".
Using slots, this means filling the "Father" slot of the unit Mary with
the value "Fred". In the second notation, the unit Mary would point to
the assertion "(Father Mary Fred)".) This first method, using explicit
slots, is "active" in the initial RLL system. If this proves
unsatifactory, a simple command will instruct RLL to switch to this second
system. From then on, (or, at least, until the user's next alterring
command,) this modified version of RLL will understand this different set
of instructions, and its reactions will follow this second convention.
Furthermore, RLL will automatically convert the user's existing data into
this new format.
To effectively use these varied components, RLL must "understand" what
each does, and how. This information allows RLL to mesh diverse parts
together, to form a coherent and working whole. As such, it should be
possible for the user to design a fairly arbitrary language by simply
choosing the precise amalgamation of these pieces he wishes; leaving to
RLL the responsibility, and headaches, of fitting them together.
Realizing this catalog of "chunks" will never be totally complete, RLL's
second approach towards generality are its collection of tools designed to
help the user fabricate new parts. These high-level operators can be used
to define a new component, (or type of component) or refine an existing
one.
For example, the user can define the "Parents" slot as the union of the
"Mother" and "Father" slots. That is, (the value of) the "Parents" slot
of an individual is a list consisting of (the values of) that person's
"Mother" and "Father" slots. This brief definition (Parent = Union(Mother
Father) ) is sufficient to tell RLL everything it needs to know about this
slot. RLL now knows to (automatically) invalidate the value stored for
Fred's parents if his mother remarries; and know that only some units may
have a Parents slots (viz. those which had both a Mother and Father slot
-- i.e. people).
Defining a new slot is trivial; designing a new inheritance, or new type
of format is as easy. The host of high-level operators considerably
lessens the complexity associated with constructing and integrating this
new piece.
These parts (however they were derived,) become the language the user can
use for his main task. If he later discovers limitations in this set of
facilities, he need only replace, or redesign the offending components.
RLL's collection of types of parts, and its high-level operators, make
either type of modification relatively simple. As shown above, RLL then
does the "busywork" -- such as reformatting the existing data to conform
to this new set of conventions.
Current Applications
While several people have expressed interest in using RLL for their
applications, the system has only recently become sufficiently stable to
permit others to use it. It has been involved in two small, internal
tasks -- an adventure game simulation and an exploration into a more
complete self-description of various of its parts, using lower-level
primitives.
An brief overview of RLL's goals can be found in [Greiner & Lenat]. This
is expanded in [Greiner], which illustrating many additional aspects of
RLL's design and implementation.
Ref:
Greiner, Russell, "A Representation Language Language", HPP Working Paper
80-9, July 1980.
Greiner, Russell and Lenat, Douglas B., "A Representation Language
Language", AAAI Conference, August 1980, Stanford.
Smith, David E., "CORLL: A Demand Paging System for Units", HPP Working
Paper 80-8, July 1980.
Received from NII 7-July (essentially final form)
RLL
Motivation
RLL is a tool to facilitiate the building of expert programs
quickly. It is itself an expert program, whose domain of expertise
is knowledge representation.
Task Description
The standard first step taken in building an application
program in AI is the design and implementation of a language that
(in which to)
represents the knowledge the program will use. Experience has shown
that the language developed in one application is seldom adaptated
for use in other programs. The features that were useful for the
original problem become limitations elsewhere. Thus, a specialized
representation language is redesigned and reimplemented for each
application -- a very time consuming task.
RLL (Representation Language Language) is designed to reduce
the time spent building such representation languages. It is a
language which "knows" about the components of representation
languages in general. It provides the user with an extendable
collection of high level operators and constructs which he can use to
describe and build components of his target language. After the user
has specified the desirable features of the target language, RLL
integrates these components into a functional, new representation
language. In other words, a user can readily and rapidly design a
personalized language, exactly suited to the domain and the
application task at hand.
RLL is an opn-ended language in which the user can add peices
of language not provided in RLL's standard repetoir. Currently RLL
can deal with pieces such as slots, modes of inheritance, and
specification of functions. Slots conform to the definition given in
the UNITS package (see page ). In fact, RLL borrowed much of its
nomenclature, as well as software, from UNITS. For example, it uses
one of UNITS main mode of inheritance, the Eample link. This
inheritance relationship corresponds to set theory notion of
"element-of". However, there is nothing in UNITS which corresponds
to RLL's use of functional specification. This domain is currently
being explored, because it would help unify many outwardly diverse
concepts, such as processes, mechanisms, and slots.
The initial RLL system is itself a very versatile
representation language. For most tasks, the user can use it as he
might any other representation language. What distinguishes RLL is
that the user is not forced to follow the constraints imposed by a
particular language; instead, he can mold his copy of RLL to
accomodate his particular task.
RLL derives this flexibility in two ways. First, RLL
contains a large library of largely independent, pre-fabricated
"representational pieces". For example, there are many (mutually
incompatible) ways in which one can associate facts with an object.
One corresponds to UNIT's idea of a slot, while another is the use of
pointer to a list or relevant assertions. For example, consider how
to represent "Fred is the Father of Mary". Using slots, "Father"
slot of the unit Mary would be filled with the value "Fred". Using
links, the unit Mary would point to the assertion "(Father Mary
Fred)". The first method, using explicit slots, is "active" in the
initial RLL system. If this proves unsatifactory, a simple command
will instruct RLL to switch to the second method. From then on,
(or, at least, until the user's next alterring command) the user
modified version of RLL will prevail. Furthermore, RLL will
automatically convert the user's existing data into the new format.
To effectively use the variety of components, RLL must
"understand" what each does, and how. This information allows RLL to
mesh diverse parts together to form a coherent and workable whole.
As such, it should be possible for the user to design a fairly
arbitrary language by simply choosing the precise amalgamation of the
pieces he needs, leaving to RLL the responsibility of fitting them
together.
Cataloging of possible components will never be totally
complete. RLL's second approach towards generality is its collection
of tools designed to help the user fabricate new parts. A set of
high-level operators are provided so that the user can define new
components or a type of components, or refine existing ones.
For example, the user can define the "Parents" slot as the
union of the "Mother" and "Father" slots. That is, the value of the
"Parents" slot of an individual is a list consisting of the values of
that person's "Mother" and "Father" slots. This brief definition,
Parent = Union(Mother Father), is sufficient to tell RLL everything it
needs to know about this slot. RLL now knows to automatically
invalidate the value stored for Fred's parents if his mother
remarries. Furthermore it knows that only some units may have a
Parents slots, i.e. those which have both a Mother and Father slots.
The language parts, however they were derived, become the
language the user can use for his task. If he later discovers
limitations in this set he need only replace or redesign the
offending components. RLL's collection of types of parts, and its
high-level operators, make modifications relatively simple. As shown
above, RLL then does the "busywork", such as reformatting the
existing data to conform to the set of new conventions.
Current Status
Although interests have been expressed in using RLL for a
variety of applications, the system has only recently become
sufficiently stable to permit others to use it. Thus far, it has
been used in two small internal tasks--an adventure game simulation
and an exploration into a more complete self-description of its
various parts using lower-level primitives.
Comparison to Editors
Units :: Bravo
- Each does somethings very nicely, but cannot be extended
or modified -- interpreted designed for limited (and known to be
constrained) set of tasks.
KRL :: E
- Both try for universality, and both fail for the same reason:
The interpreter cannot be changed. Although other effects can be
simulated, that's as close as one can get.
ROSIE :: IBM's Editor
- Both were designed to be learned easily, and to be inextendable.
(Rosie's aims differ slightly from Unit's:
Rosie's purpose is for each of understanding; as opposed to
representational generality -- Units avoids these linguistic issues
for the most part.)
RLL-1 :: EMACS
- Both are very general languages, designed to be modified (and to
facilitate such modifications). Both establish some initial
conventions: RLL-1 has slots, EMACS is defined exclusively for screen
displays.
MRS :: TECO
- Both are bare-bones -- just enough to get started, and to be massaged
into the form desired.
(Note EMACS can be [in fact, was] written in TECO.)
Language metaphor
Representation Languages share many similiarities with natural languages,
such as English.
Both can be used to express facts about the world,
and in both cases, such descriptions are in terms of very high level, and "natural"
units.
Both are open-ended, and extendable --
new terms can be formed from old, using various established methods.
(New words can be created by adding a prefix to an existing word.
One can infer the meaning of "verbifying", as it applies a standard
method by verbifying to the noun, "verb".
Also, a word can take on a new, or extended meaning,
by using it in a new context.)
A language is more than just a dictionary of words;
it also includes a grammar which describes
how to use words to form higher level constructs,
such as Noun Phrase, Sentence, or Story.
RLL is like a very general purpose language,
which contains a large number of words, and a very encompassing grammar.
Many users will be able to use this, sans alterations.
What distinquishes RLL from most other representational languages is its
ability to change.
It can built not only new words,
but new and different grammars as well.
Most systems impose a fairly rigid set of conventions on what they can do,
and how.
The user has no choice but to conform to these standards,
which forces some applications into awkward contortions, if it is at all possible.
It achieves this generality by describing these each of notions precisely;
representing them within RLL's own formalisms
(much like reading an text on English, written in English).
These descriptions can then be used.
A user can combine the desired features
of several distinct languages to form
a new, specialized language, suited to his particular needs and goals.
Our eventual goal is to provide an entire catalog of these language
provides the ability to shift amoung languages -- to use German's
capability to string nouns together, and
Ref:
Extensible langauge, for describing extensibilites:
Davis, Randall, "Generalized procedure calling and content-directed invocation",
SIGPLAN Noices, Vol. 12, Nol 8, August 1977, pp. 45-54
Same general ideas - of bootstrapping down & down
Sandewall, Erik, "?", IJCAI 4
Smalltalk - idea of each unit knowing what to do
Fahlman "<10% not easy to represent, and require special fixes"
[see IJCAI-79, p.282 - in article re: AMORD]
Fox (IJCAI-79 282-4) - make things as explicit as possible - and declarative
Georgeff (IJCAI-79 330) - can add semantics to MetaRules easily
[use Cogn Econ to decide what needs to be recomputed]
Laubsh (IJCAI-79 516) [W German] {ATN w/Sem Nets} put concepts into Units,
with additional facts
Leitner, Henry H (Harvard) & Micheal W Freeman(Burroughs), (IJCAI-79 525)
store with "slot" what to do
Miller, G.A., E. Galanter, and K H Pribaum "Plans & the Structure of Behaviour,
New York: Holt, Rinehard & Winston, 1960. (see IJCAI-79 555)
"Major source of new plans is old plans."
Mostow & Hayes-Roth (IJCAI-79 601) - schema for heuristic search, w/slots for facts
IJCAI-79, 617 - AKO limiting - as meaning too many things, and all imprecisely
Semantics not pure (618)
"Prespecitifed useages of attached procedures is too restrictive"
(but they still stop shrt of real soln - ie they add own (deepter) conventions)
Hayes "Defense of Logic" - refers to building an interpreter for the interpreter
[see also Stefik's HPP-80-13, appearing in ?Artificial Intelligence? 1980]